One of the key factors in the performance of a computer system is the speed at which the central processing unit (CPU) operates. Generally, the faster the CPU operates, the faster the computer system can complete a designated task. Another method of increasing the speed of a computer system is through the use of multiple CPUs. This is commonly known as multiprocessing. With multiple CPUs, algorithms required to complete a task can be executed substantially in parallel as opposed to their sequential execution, thereby decreasing the total time to complete the task.
However, as CPUs are dependent upon peripherals for providing data to the CPU and storing the processed data from the CPU, when a CPU needs to read or write to a peripheral, the CPU is diverted from a current algorithm to execute the read/write transaction. As can be appreciated, the length of time that the CPU is diverted is typically dependent upon the speed of the I/O transaction.
One advancement developed to increase the efficiency of I/O transactions is the intelligent input/output (I2O) architecture. In the I2O approach to I/O, low-level interrupts are off loaded from a CPU to I/O processors (IOPs). The IOPs are additional processors that specifically handle I/O With support for message-passing between multiple independent processors, the I2O architecture relieves the host processor of interrupt-intensive I/O tasks, greatly improving I/O performance especially in high-bandwidth applications such as networked video, groupware, and client/server processing.
Typical I2O architectures use a “split driver” model which inserts a messaging layer between the portion of the device driver specific to the operating system and the portion of the device driver specific to the peripheral. The messaging layer splits the single device driver of today into two separate modules, an Operating System Service Module (OSM), and a Downloadable Driver Module (DDM). The only interaction one module has with another module is through this messaging layer.
The OSM comprises the portion of the device driver which is specific to the operating system. The OSM interfaces with the operating system of the computer system (which is commonly referred to in the art as the “host operating system”) and is executed by the CPU. Typically, a single OSM may be used to service a specific class of peripherals. For example, one OSM would be used to service all block storage devices, such as hard disk drives, and CD-ROM drives.
The DDM provides the peripheral-specific portion of the device driver that understands how to interface to the particular peripheral hardware. To execute the DDM, an IOP is added to the computer system. A single IOP may be associated with multiple peripherals, each controlled by a particular DDM, and contains its own operating system such as, for example, the I2O Real-Time Operating System (iRTOS). The DDM directly controls the peripheral, and is executed by the IOP under the management of the iRTOS.
In general operation, the communications model used in the I2O architecture is a message passing system. When the CPU seeks to read or write to a peripheral in an I2O system, the host operating system makes what is known as a “request”. The OSM translates the request by the host operating system and, in turn, generates a message. The OSM sends the message across the messaging layer to the DDM associated with the peripheral which processes it appropriately to achieve a result. Upon completion of the processing, the DDM sends the result back to the OSM by sending a message through the messaging layer. It can be appreciated that to the host operating system, the OSM appears just like any other device driver.
By executing the DDM on the IOP, the time-consuming portion of transferring information from and to the peripheral hardware is off-loaded from the CPU to the IOP With this off-loading, the CPU is no longer diverted for inordinate amounts of time during an I/O transaction. Moreover, because the IOP is a hardware component essentially dedicated to the processing of the I/O transactions, the problem of I/O bottlenecking is mitigated. Accordingly, any performance gains to be achieved by adding an additional or faster CPU to the computer system may be unhindered by the I/O processing bottleneck.
There are three common approaches to implement the I2O architecture. The first is an IOP installed on the motherboard of the computer system. In this approach, the IOP is installed directly on the motherboard and is used for I2O processing. In this particular configuration, the IOP is often used as a standard PCI bridge, and can also be used to bring intelligence to the PCI bus.
The second approach is to include an IOP on adapter cards, such that with an IOP on an adapter card, IT managers can add intelligent I/O to the computer system by adding an additional adapter.
The third approach is to install the IOP in the computer system via an optional plug-in card. This allows systems to be populated with one IOP per host adapter plugged into a slot instead of on the motherboard.
Although the intent of I2O was the implementation of portable, high-performance intelligent I/O systems there exists a number of problems with I2O architecture. As is often the case, one problem is cost. The inclusion or the addition of additional hardware and extra processors (the IOPs) to a computer system will ultimately raise the price of the system.
Another problem arises as a result of the direction the computer industry has taken in the adoption of an IOP “standard”. Currently, the computer industry is pushing to adopt the Intel i960 processor for the industry standard I2O IOP Some of the problems with the i960 include computing and speed problems, especially when the i960 is compared to other existing processors on the market.
In a multiprocessor system environment one proposed solution to the i960 IOP is to use software to solely dedicate at least one of the host processors to controlling the I/O. As can be appreciated, current system processors have very superior computing power and speed as compared with the i960. Another advantage of a host processor IOP is that no additional hardware needs to be purchased or added. This is especially true when upgrading an existing computer system to be I2O compliant. However, in making a computer system I2O compliant by dedicating a host processor, many problems have been encountered. One problem is making the dedicated host processor appear to the rest of the computer system to be an I2O IOP in a seamless manner. It is desired that a computer system having a host processor IOP appear to a user to be a typical I2O compliant computer system in all aspects including software interaction and hardware interaction.
Many existing computer systems utilize kernel based operating systems In a kernel based operating system, such as Windows NT, the operating system has a layered architecture. In this type of operating system, the kernel is at the core of the layered architecture and manages only basic operating system functions. The kernel is responsible for thread dispatching, multiprocessor synchronization, and hardware exception handling.
Another piece of software often associated with the operating system is the hardware abstraction layer (HAL). The HAL is an isolation layer of software that hides, or abstracts hardware differences from higher layers of the operating systems. Because of the HAL, the different types of hardware all look alike to the operating system, removing the need to specifically tailor the operating system to the hardware with which it communicates. Ideally, the HAL provides routines that allow a single device driver to support the same device on all platforms.
HAL routines can be called from both the base operating system, including the kernel, and from device drivers. The HAL enables device drivers to support a wide variety of I/O architectures without having to be extensively modified. The HAL is also responsible for hiding the details of symmetric multiprocessing hardware from the rest of the operating system.
In the early days of Windows NT, it was common practice for the hardware OEMs to be responsible for providing the HAL software for their particular hardware to the manufacturer of the operating system. As multiprocessing systems became more commonplace, there was a shift from the hardware OEMs supplying the HAL routines, to the OS manufacturer supplying the HAL routines for all the hardware OEMs.
Therefore, as can be further appreciated, when making of a computer system I2O compliant by dedicating at least one of the host processors for an IOP, it is not practical to modify an existing operating system or HAL Rather it would be more advantageous to provide “routines” that are seamlessly hooked into the operating system.